Vi får udleveret et næsten færdigt skelet for et OS-API.
Det smarte ved disse API er at vi kan bygge programmer som kan fungere på flere platforme. Man kan altså bygge et program, og så bruge OS-API som en adaptor som kan pladseres ovenpå, på denne måde passer den ind flere steder, dette spare både tid og penge da man kun skal lave samme program en gang, ligeledes kan man i virksomheder komme ud for at man skifte OS og derved have flere programmer der ikke fungere med API vil dette være muligt.
Mappetrået til vores OS-API er opdelt sådan at filer der bruges flere steder er samlet, ligeledes er alle hpp filer til disse tilhørende, samlet under samme mapper.
Filer som er specifikke for OS er pladseret i common, disse idiomer er f.eks. ScopeLock, Message-queue...
I det udleverede materialer var der altså nogle filer der var lavet, andre som vi skulle lave til linux delen.
Da vi først satte os for at kigge på de dele vi selv skulle kode, startede et stort spørgsmål tegn, de anviste sider der skulle læses til lektionen blev læst igen uden held. Efter som google er blevet en god ven blev denne benyttet og efter lidt tid gik det op for os at de filer vi skulle lave selv, stort set skulle være de samme som dem der blev brugt til win32. Derfor blev disse kopiert, Nogle ting hed noget forskelligt, f.eks i win32 bruges CriticalSection hvor vi i linux bruger pthread_mutex.
Mutex.cpp
Når vi arbejder på denne måde vil vi selvfølgelig også gerne gøre sådan at koden bliver mest optimeret, derfor vil vi gerne at flere af de funktioner vi benytter gør det samme, eller i vært fald kan kalde både win32 og linux delene.
Dette gør vi f.eks. i "void Conditional::wait(Mutex& mut)" hvor vi kalder to ting, om det er linux kalder vi pthread_mutex og om det er win32 kalder vi CRITICAL_SECTION.
Spørgsmål der skal besvares
¤ Why does the ThreadTest.cpp program behave di erently depending on whether you are running it on a single processor or multi processor system and how is this experienced?
grunden til at vores ThreadTest.cpp agerer forskelligt alt efter om den kører på en processor eller flere er at vi ved en processor kun kan behandle en stump data af gangen hvor vi ved flere processorer kan behandle flere stumper data parallelt og det bliver herved hen stump data der er færdigbehandlet først der bliver sendt ud på skærmen.
¤ The le linux/Conditional.cpp
In completing this le you will encounter the term CLOCK MONOTONIC. Whatdoes this mean and how does it distinguish itself from the other clock setup options
that are possible?
den monotone clock er repræsenterer en tid fra tidligere Real time clock representere en tid der kører nu og denne følger også ændringerne i NTP.
Why could this possibly be important? Hint: NTP and setting time.
Ved en Monotonic clock vil vi ikke risikere at tiden pludselig springer hvis NTP justere tiden, Ved Monotonic er vi også sikre på at tråden sover i den tid vi har bestemt.
Da vi skulle compile for host and target gør dte ingen forskel i selve vores kode. Forskellen ligge rover i make filen som vi beder om at compile til de to forskellige. På denne måde får vi en mappe der hedder host og en der hedder target og i disse kan vi så finde de compilede filer for disse to.
DEL 3
Om mange ændringer og hvad:
Vi benytter nu OSApi i vores lille program på den måde at vi har ændret tråde og besked kø til at benytte denne i stedet for pthread, på denne måde optimere vi koden og gør at programmet vi OSApi kan compiles til de forskellige platforme som vi har lavet OSApi til.
Vi er nu ikke afhængig af POSIX og det betyder at programmet nu meget simpelt kan flyttes imellem linux og windows.
Ved at benytte et OSApi bliver programmet på et højere abstractiuons niveau som hjælper med at mindske fejl.
Vi får udleveret et næsten færdigt skelet for et OS-API.
Det smarte ved disse API er at vi kan bygge programmer som kan fungere på flere platforme. Man kan altså bygge et program, og så bruge OS-API som en adaptor som kan pladseres ovenpå, på denne måde passer den ind flere steder, dette spare både tid og penge da man kun skal lave samme program en gang, ligeledes kan man i virksomheder komme ud for at man skifte OS og derved have flere programmer der ikke fungere med API vil dette være muligt.
Mappetrået til vores OS-API er opdelt sådan at filer der bruges flere steder er samlet, ligeledes er alle hpp filer til disse tilhørende, samlet under samme mapper.
Filer som er specifikke for OS er pladseret i common, disse idiomer er f.eks. ScopeLock, Message-queue...
I det udleverede materialer var der altså nogle filer der var lavet, andre som vi skulle lave til linux delen.
Da vi først satte os for at kigge på de dele vi selv skulle kode, startede et stort spørgsmål tegn, de anviste sider der skulle læses til lektionen blev læst igen uden held. Efter som google er blevet en god ven blev denne benyttet og efter lidt tid gik det op for os at de filer vi skulle lave selv, stort set skulle være de samme som dem der blev brugt til win32. Derfor blev disse kopiert, Nogle ting hed noget forskelligt, f.eks i win32 bruges CriticalSection hvor vi i linux bruger pthread_mutex.
Mutex.cpp
namespace osapi { Mutex::Mutex() { pthread_mutex_init(&m_, 0); //InitializeCriticalSection(&cs_); } void Mutex::lock() { pthreaad_mutex_lock(&m_); // EnterCriticalSection(&cs_); } void Mutex::unlock() { pthread_mutex_unlock(&m_); //LeaveCriticalSection (&cs_); } pthread_mutex_t& Mutex::nativeHandle() { return m_; //return cs_; } Mutex::~Mutex() { pthread_mutex_destroy(&m_); //DeleteCriticalSection(&cs_); // Ignores return value, may not through an exception anyway } }Mutex.hppusing namespace std; namespace osapi { class Mutex : Notcopyable { public: Mutex(); void lock(); void unlock(); pthread_mutex_t& nativeHandle(); //CRITICAL_SECTION& nativHandle(); ~Mutex(); private: pthread_mutex_t m_; //CRITICAL_SECTION cd_; }; }Når vi arbejder på denne måde vil vi selvfølgelig også gerne gøre sådan at koden bliver mest optimeret, derfor vil vi gerne at flere af de funktioner vi benytter gør det samme, eller i vært fald kan kalde både win32 og linux delene.
Dette gør vi f.eks. i "void Conditional::wait(Mutex& mut)" hvor vi kalder to ting, om det er linux kalder vi pthread_mutex og om det er win32 kalder vi CRITICAL_SECTION.
Spørgsmål der skal besvares
¤ Why does the ThreadTest.cpp program behave di erently depending on whether you are running it on a single processor or multi processor system and how is this experienced?
grunden til at vores ThreadTest.cpp agerer forskelligt alt efter om den kører på en processor eller flere er at vi ved en processor kun kan behandle en stump data af gangen hvor vi ved flere processorer kan behandle flere stumper data parallelt og det bliver herved hen stump data der er færdigbehandlet først der bliver sendt ud på skærmen.
¤ The le linux/Conditional.cpp
that are possible?
den monotone clock er repræsenterer en tid fra tidligere
Real time clock representere en tid der kører nu og denne følger også ændringerne i NTP.
Ved en Monotonic clock vil vi ikke risikere at tiden pludselig springer hvis NTP justere tiden, Ved Monotonic er vi også sikre på at tråden sover i den tid vi har bestemt.
2) compile for host og target
Vi kan se at filen
Compilet for target
Da vi skulle compile for host and target gør dte ingen forskel i selve vores kode. Forskellen ligge rover i make filen som vi beder om at compile til de to forskellige. På denne måde får vi en mappe der hedder host og en der hedder target og i disse kan vi så finde de compilede filer for disse to.
DEL 3
Om mange ændringer og hvad:
Vi benytter nu OSApi i vores lille program på den måde at vi har ændret tråde og besked kø til at benytte denne i stedet for pthread, på denne måde optimere vi koden og gør at programmet vi OSApi kan compiles til de forskellige platforme som vi har lavet OSApi til.
Vi er nu ikke afhængig af POSIX og det betyder at programmet nu meget simpelt kan flyttes imellem linux og windows.
Ved at benytte et OSApi bliver programmet på et højere abstractiuons niveau som hjælper med at mindske fejl.
Udplot fra kode (main.cpp):
class CarThread : public osapi::Thread { public: CarThread() : osapi::Thread(PRIORITY_NORMAL), m_state(ENTER){ }; void run() { while(1){ switch(m_state) { case ENTER: { // // Send // std::cout << "Car send request" << std::endl; EntryReq *entry_req = new EntryReq(); entry_req->mq_ = &car_queue; control_queue.send(ID_ENTRY_REQ,entry_req); // // Receive // std::cout << "Car receive request" << std::endl; unsigned long id; Message *msg = car_queue.receive(id); if(carHandler(msg,id)) { m_state = SLEEP; } break; }kode